제6장 설계 원칙
TP의 설계는 다섯 가지 핵심 원칙을 중심으로 전개됩니다. 이 원칙들은 프로토콜 자체의 기술 설계를 안내할 뿐만 아니라, TP 생태계의 모든 참여자가 준수해야 할 행동 기준을 정의합니다.
6.1 공유 인지가 메시지 전달보다 우선
TP의 최우선 설계 원칙은: 가능한 경우, 메시지의 직렬화 전송에 의존하기보다 공유 인지 공간을 구축하는 것을 우선시한다는 것입니다. 메시지 전달 모드는 매 상호작용마다 인코딩 손실, 전송 지연, 시맨틱 모호성을 초래합니다. 반면 공유 인지 모드는 협업 양측이 동일한 인지 리소스에 직접 접근하게 하여 정보 전달의 마찰을 근본적으로 제거합니다. 이 원칙은 메시지 전달의 가치를 부정하지 않습니다. 공유 공간을 구축하는 것 자체에 메시지 협상이 필요하기 때문입니다. 그러나 TP의 설계 방향을 명확히 합니다: 불필요한 직렬화와 역직렬화를 최대한 줄인다는 것입니다.
현실 사례: 두 Fay가 교통사고 보험금 청구를 협업 처리합니다. 메시지 전달 모드에서는 보험 Fay가 손해 사정 Fay에게 완전한 사고 보고서, 사진, 차량 정보, 보험 증권 상세 정보를 전송해야 합니다. 매 통신마다 대량의 데이터를 패키징하여 전송합니다. 공유 인지 모드에서는 양측이 공유 컨텍스트를 구축하고, 사고 보고서, 사진, 보험 증권 정보가 공유 공간에 마운트됩니다. 손해 사정 Fay가 공유 공간에서 직접 조회하고 마크업하며, 보험 Fay가 마크업 결과를 실시간으로 확인합니다. 전체 과정은 마치 두 보험 사정인이 같은 테이블에 앉아 동일한 서류철을 넘기는 것과 같습니다.
6.2 전송 무관성
TP가 관심을 두는 것은 시맨틱 계층이지 전송 계층이 아닙니다. TP 메시지는 A2A의 JSON-RPC, MCP의 tool call, 기존 REST API, 심지어 자연어 Prompt를 통해 전달될 수 있습니다. 이 원칙은 TP가 어떤 단일 하위 프로토콜에도 바인딩되지 않도록 보장합니다. 새로운 전송 방식이 등장하면 TP는 전송 어댑터만 추가하면 되며, 프로토콜 자체의 시맨틱 정의를 수정할 필요가 없습니다. 전송 무관성은 또한 TP가 본질적으로 전방 호환 능력을 갖추고 있음을 의미합니다. 아직 발명되지 않은 전송 프로토콜에도 적응할 수 있습니다.
현실 사례: 클라우드에서 실행되는 기업 Fay가 엣지 디바이스(예: 공장 센서 게이트웨이)에서 실행되는 Fay와 통신해야 합니다. 클라우드 Fay는 A2A를 네이티브로 지원하지만, 엣지 디바이스에는 간단한 REST API만 있습니다. TP의 전송 무관성 덕분에 양측은 상대방의 전송 능력을 신경 쓸 필요가 없습니다. TP가 자동으로 적응하여 클라우드 Fay가 A2A로 보낸 의도가 투명하게 REST API 호출로 번역되어 엣지 디바이스에 전달됩니다.
6.3 자적응 프로토콜 협상
이기종 AI 생태계에서 서로 다른 Fay는 서로 다른 프로토콜 언어를 "사용"할 수 있습니다. TP는 모든 참여자에게 통일된 전송 프로토콜을 요구하지 않고, 자적응 협상 및 번역 메커니즘을 통해 "모국어"가 다른 Fay가 원활하게 통신할 수 있도록 합니다. 협상 과정은 능력 탐지, 계약 협상, 시맨틱 매핑의 세 단계를 포함하며, 크로스 프로토콜 번역 과정에서 의도의 시맨틱이 손실되지 않도록 보장합니다. 이 원칙은 TP 생태계의 진입 장벽을 낮춥니다. 최소 하나의 전송 방식을 지원하는 모든 Fay가 TP 통신에 참여할 수 있습니다.
현실 사례: 다국적 기업의 HR Fay가 각국의 사회보험 기관 coFay와 연동해야 합니다. 미국의 사회보험 coFay는 A2A를 사용하고, 일본은 MCP tool call을 사용하며, EU는 REST API를 사용합니다. HR Fay는 각 국가별로 다른 연동 코드를 작성할 필요가 없습니다. TP가 세션 수립 시 상대방의 프로토콜 능력을 자동으로 탐지하고, 양측이 모두 지원하는 전송 방식을 협상하며, 이후 통신은 완전히 투명하게 이루어집니다.
6.4 Host 주권 프라이버시
iFay의 세계관에서 각 Fay는 Host를 대리하여 행동합니다. 따라서 Host는 자신의 데이터에 대해 절대적인 주권을 가집니다. Fay는 어떤 인지 리소스를 공유할지 자체적으로 결정할 수 없습니다. 모든 데이터 공개는 Host가 사전에 인가한 범위 내에서 이루어져야 합니다. TP는 엔드투엔드 암호화, 선택적 공개(SelectiveDisclosure), 유효 기간이 있는 콜백 자격 증명(CallbackCredential)의 삼중 메커니즘을 통해 Host의 프라이버시 데이터가 전송 및 접근 과정에서 항상 보호되도록 보장합니다. Host는 언제든지 인가를 철회하고 데이터 공유를 종료할 수 있습니다.
현실 사례: 사용자의 iFay가 사용자를 대리하여 은행 coFay에 대출을 신청합니다. 은행은 사용자의 소득 증명과 신용 기록을 확인해야 하지만, 사용자는 은행이 자신의 소비 내역과 투자 포트폴리오를 보는 것을 원하지 않습니다. 사용자는 인가 시 "최근 12개월 급여 명세와 신용 점수만 공개 허용"이라고 명시적으로 지정하며, iFay가 선택적 공개 메커니즘을 통해 이 두 항목의 데이터만 노출합니다. 대출 심사가 완료되면 콜백 자격 증명이 자동으로 만료되어 은행 coFay는 더 이상 사용자 데이터에 접근할 수 없습니다. 사용자가 중간에 마음을 바꾸면 언제든지 인가를 철회하여 즉시 데이터 공유를 종료할 수 있습니다.
6.5 감사 가능한 신뢰 경계
신뢰는 맹목적이어서는 안 됩니다. 검증 가능한 기반 위에 구축되어야 합니다. TP는 프라이버시 데이터 접근, 자격 증명 사용, Fay 간 통신과 관련된 모든 작업이 감사 가능할 것을 요구합니다. 감사 기록에는 작업 유형, 참여자 신원, 타임스탬프, 접근 범위가 포함되지만, 실제 데이터 내용이나 자격 증명 토큰 평문은 포함되지 않습니다. Host는 언제든지 감사 로그를 열람하여 자신의 데이터가 누구에 의해, 언제, 어떤 목적으로 접근되었는지 확인할 수 있습니다. 이 원칙은 TP 생태계의 신뢰가 투명하고 추적 가능하도록 보장합니다.
현실 사례: 환자의 iFay가 지난 한 달간 의료 coFay, 보험 coFay, 약국 coFay와 여러 차례 상호작용했습니다. 환자는 감사 로그를 열어 다음과 같은 기록을 확인할 수 있습니다: "4월 3일 14:23, 의료 coFay가 귀하의 알레르기 이력에 접근했습니다 (인가 범위: 진단 관련 데이터)", "4월 5일 09:15, 보험 coFay가 콜백 자격 증명을 통해 진단 코드와 비용 명세에 접근했습니다 (자격 증명은 4월 5일 17:00에 만료됨)". 이것은 마치 은행 계좌의 거래 내역을 조회하는 것과 같습니다. 모든 "데이터 거래"가 기록으로 남아 있습니다.